src/routes/package/SidePanel.svelte (1)

185-191: Add error handling for async badge data (duplicate pattern).

Similar to the previous comment, this second instance of badge data awaiting also needs error handling.

src/routes/package/+layout.server.ts (2)

60-70: Repeated sort() inside loop is an unnecessary hotspot

Inside the validReleases loop you compute currentNewestVersion by converting the Set to an array and calling semver.rcompare every iteration.
On large repositories this becomes O(R² log R). Track the newest version incrementally instead:

-				const currentNewestVersion = [...foundVersions].sort(semver.rcompare)[0];
-				// …
-				foundVersions.add(cleanVersion);
-				releases.push({ cleanName, cleanVersion, ...release });
-
-				// If it is newer than the newest we got, set this repo as the "final repo"
-				if (!currentNewestVersion || semver.gt(cleanVersion, currentNewestVersion)) {
+				const isNewer =
+					!globalThis.__newestVersion ||
+					semver.gt(cleanVersion, globalThis.__newestVersion);
+				foundVersions.add(cleanVersion);
+				releases.push({ cleanName, cleanVersion, ...release });
+
+				if (isNewer) {
+					globalThis.__newestVersion = cleanVersion;
 					// …
 				}

(Use a local variable instead of globalThis; shown only for brevity.)

This removes the per-iteration sort while preserving behaviour.

---

128-137: Missing type on exported load reduces DX

The SvelteKit load hook can be typed via LayoutServerLoad to enable auto-completion in consumers:

-import type { LayoutServerLoad } from './$types'; // adjust relative path
-
-export async function load() {
+import type { LayoutServerLoad } from './$types';
+
+export const load: LayoutServerLoad = async () => {
   // …
-	return { allReleases };
-}
+	return { allReleases };
+};

Helps tooling catch accidental shape changes early.

src/routes/package/[...package]/+page.svelte (1)

25-27: localStorage write fires on every state change

$effect executes on all reactive updates, so toggling showPrereleases, accordion state, etc. will rewrite the same key many times per session. A one-off onMount is sufficient and cheaper:

-import { onMount } from "svelte";
-
-$effect(() => {
-  localStorage.setItem(`last-visited-${data.currentPackage.pkg.name}`, new Date().toISOString());
-});
+import { onMount } from "svelte";
+
+onMount(() => {
+  try {
+    localStorage.setItem(
+      `last-visited-${data.currentPackage.pkg.name}`,
+      new Date().toISOString()
+    );
+  } catch {
+    /* SSR or private-mode fallback – ignore */
+  }
+});

Also guards against SSR and private-mode QuotaExceededError.

src/routes/package/SidePanel.svelte (2)

81-98: Consider adding error handling for localStorage.

While there is a browser check at line 89, it would be better to add a try-catch block around localStorage operations to handle potential exceptions in private browsing modes or when storage is full.

function getUnvisitedReleases(pkgName: string, releases: CleanRelease[] | undefined) {
  if (!releases || !browser) return [];

-  const lastVisitedItem = localStorage.getItem(`last-visited-${pkgName}`);
-  if (!lastVisitedItem) return [];
-  const lastVisitedDate = new Date(lastVisitedItem);
+  try {
+    const lastVisitedItem = localStorage.getItem(`last-visited-${pkgName}`);
+    if (!lastVisitedItem) return [];
+    const lastVisitedDate = new Date(lastVisitedItem);
+
+    return releases.filter(
+      ({ created_at, published_at }) => new Date(published_at ?? created_at) > lastVisitedDate
+    );
+  } catch (error) {
+    console.error(`Error accessing localStorage for ${pkgName}:`, error);
+    return [];
+  }
-
-  return releases.filter(
-    ({ created_at, published_at }) => new Date(published_at ?? created_at) > lastVisitedDate
-  );
}

---

152-159: Add error handling for async badge data.

The await block for badge data doesn't include error handling. Consider adding an error branch to gracefully handle failed requests.

{#if linkedBadgeData}
-  {#await linkedBadgeData then data}
+  {#await linkedBadgeData}
+    <!-- Optional loading state -->
+  {:then data}
    {@render newBadge(
      getUnvisitedReleases(pkg.name, data?.releases).length
    )}
+  {:catch error}
+    <!-- Silently fail or show minimal error indicator -->
+    <span class="text-xs text-muted-foreground" title="Failed to load badge data">!</span>
+  {/await}
{/if}

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: WarningImHack3r
PR: WarningImHack3r/svelte-changelog#48
File: src/routes/package/[...package]/+page.server.ts:50-53
Timestamp: 2025-04-11T10:33:07.002Z
Learning: WarningImHack3r prefers to keep server-side console.log statements in the codebase as they find them useful for debugging and monitoring, even if they might clean them up later.

src/routes/package/SidePanel.svelte (1)

220-241: Excellent tooltip implementation for disabled checkbox

Great implementation of the tooltip to explain the disabled state of the prereleases checkbox. This addresses the previous review comment and follows UI best practices by clearly communicating to users why the control is disabled.

src/routes/package/SidePanel.svelte (5)

89-105: Add error handling for localStorage operations

The getUnvisitedReleases function directly accesses localStorage without any error handling. While the browser check helps, various scenarios (private browsing, storage quota exceeded, etc.) could cause these operations to fail.

Consider adding try-catch blocks around the localStorage operations:

function getUnvisitedReleases(pkgName: string, releases: CleanRelease[] | undefined) {
  if (!releases || !browser) return [];

+ let lastVisitedItem;
+ try {
    const lastVisitedItem = localStorage.getItem(`last-visited-${pkgName}`);
+ } catch (error) {
+   console.warn(`Failed to access localStorage for ${pkgName}:`, error);
+   return releases.filter(
+     ({ created_at, published_at }) =>
+       new Date(published_at ?? created_at).getTime() >
+       new Date().getTime() - 1000 * 60 * 60 * 24 * 7
+   );
+ }
  
  if (!lastVisitedItem) {
    return releases.filter(
      ({ created_at, published_at }) =>
        new Date(published_at ?? created_at).getTime() >
        new Date().getTime() - 1000 * 60 * 60 * 24 * 7
    );
  }
  const lastVisitedDate = new Date(lastVisitedItem);

  return releases.filter(
    ({ created_at, published_at }) => new Date(published_at ?? created_at) > lastVisitedDate
  );
}

---

59-64: Consider potential race conditions in the nested effects

The nested effects used for persisting the prerelease state could potentially lead to race conditions or unnecessary updates if packageName and showPrereleases change simultaneously.

Consider refactoring to use a single effect that depends on both values:

-$effect(() => {
-	let storedPrereleaseState = persisted(`show-${packageName}-prereleases`, showPrereleases);
-	$effect(() => {
-		storedPrereleaseState.value = showPrereleases;
-	});
-});
+$effect(() => {
+	let storedPrereleaseState = persisted(`show-${packageName}-prereleases`, showPrereleases);
+	storedPrereleaseState.value = showPrereleases;
+});

---

73-80: Optimize package name comparison in getBadgeDataFromOther

The current implementation searches through all entries in otherReleases to find a match, which could be inefficient for a large number of packages.

Consider using direct property access with case normalization:

function getBadgeDataFromOther(pkgName: string) {
-	const data = Object.entries(otherReleases).find(
-		([k]) => k.localeCompare(pkgName, undefined, { sensitivity: "base" }) === 0
-	);
-	if (!data) return undefined;
-	const [, v] = data;
-	return v;
+	// Try direct access first
+	if (otherReleases[pkgName]) return otherReleases[pkgName];
+	
+	// Fall back to case-insensitive search
+	const normalizedPkgName = pkgName.toLowerCase();
+	for (const [k, v] of Object.entries(otherReleases)) {
+		if (k.toLowerCase() === normalizedPkgName) return v;
+	}
+	
+	return undefined;
}

---

96-97: Use constants for magic numbers

The code uses magic numbers for calculating the week timeframe (1000 * 60 * 60 * 24 * 7).

Extract this calculation into a named constant for better readability:

function getUnvisitedReleases(pkgName: string, releases: CleanRelease[] | undefined) {
  if (!releases || !browser) return [];

+ const ONE_WEEK_MS = 1000 * 60 * 60 * 24 * 7;
+
  const lastVisitedItem = localStorage.getItem(`last-visited-${pkgName}`);
  if (!lastVisitedItem) {
    return releases.filter(
      ({ created_at, published_at }) =>
        new Date(published_at ?? created_at).getTime() >
-       new Date().getTime() - 1000 * 60 * 60 * 24 * 7
+       new Date().getTime() - ONE_WEEK_MS
    );
  }
  // ...rest of function
}

---

94-98: Avoid code duplication in date filtering logic

There's duplicate date comparison logic between the two filter conditions.

Refactor to reuse the date comparison logic:

function getUnvisitedReleases(pkgName: string, releases: CleanRelease[] | undefined) {
  if (!releases || !browser) return [];

+ const ONE_WEEK_MS = 1000 * 60 * 60 * 24 * 7;
+ const compareDate = new Date(localStorage.getItem(`last-visited-${pkgName}`)) || 
+   new Date(new Date().getTime() - ONE_WEEK_MS);
+
+ return releases.filter(
+   ({ created_at, published_at }) => 
+     new Date(published_at ?? created_at) > compareDate
+ );
-  const lastVisitedItem = localStorage.getItem(`last-visited-${pkgName}`);
-  if (!lastVisitedItem) {
-    return releases.filter(
-      ({ created_at, published_at }) =>
-        new Date(published_at ?? created_at).getTime() >
-        new Date().getTime() - 1000 * 60 * 60 * 24 * 7
-    );
-  }
-  const lastVisitedDate = new Date(lastVisitedItem);
-
-  return releases.filter(
-    ({ created_at, published_at }) => new Date(published_at ?? created_at) > lastVisitedDate
-  );
}

Also applies to: 102-104

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: WarningImHack3r
PR: WarningImHack3r/svelte-changelog#56
File: src/routes/package/+layout.server.ts:28-40
Timestamp: 2025-04-25T10:58:24.052Z
Learning: WarningImHack3r prefers elegant, aesthetically pleasing solutions for performance optimizations rather than quick fixes that introduce nested async IIFEs or similar approaches that might make code harder to read.

Learnt from: WarningImHack3r
PR: WarningImHack3r/svelte-changelog#48
File: src/routes/package/[...package]/+page.server.ts:50-53
Timestamp: 2025-04-11T10:33:07.002Z
Learning: WarningImHack3r prefers to keep server-side console.log statements in the codebase as they find them useful for debugging and monitoring, even if they might clean them up later.